Today seems to be Firefox/Iceweasel 3 Bashing Day on Planet Debian, so let me join the fun :) I agree with most other people that the default Firefox/Iceweasel 3 config is not ideal, so here's what I did to fix it. Some of these items improve performance, some remove annoyances, some remove privacy issues, some remove security issues. Not everything here may be desirable for people other than me. General

• Disable the bookmarks toolbar via "View / Toolbars / Bookmarks Toolbar", nobody needs that and we save some screen space. Remove all pre-defined bookmarks while we're at it.
• Select "View / Toolbars / Customize".
  • Add the "New Tab" button/icon right after the "Home" button. This is probably the most-used button (for me at least) and it's not available per default...
  • Click "Use Small Icons", there's no reason to waste screen space.
  • Remove the Google search bar (useless).
  • Now move all icons and the URL bar into the menu bar (I'm not kidding). After that you can disable the nagivation toolbar via "View / Toolbars / Navigation Toolbar" and save even more screen space.

Preferences Select "Edit / Preferences". Main:

• Select "When Iceweasel starts: Show a blank page".
• Set "Home Page" to whatever you see fit.

Tabs:

• Enable "Always show the tab bar".

Content:

• At the right-hand side of "Enable JavaScript" click "Advanced" and uncheck all checkboxes. JavaScript stuff shouldn't need to do any of those operations.
• Uncheck "Enable Java". Nobody needs this crap and it's a huge security risk.

Privacy:

• Disable "Keep my history for xyz days" completely. Huge privacy risks.
• Disable "Remember what I enter in forms and the search bar". Huge security and privacy risks, almost no gain.
• Disable "Remember what I've downloaded". Huge privacy risks.
• Uncheck "Accept third-party cookies".
• Choose "Keep until: I close Iceweasel".
• Click "Show Cookies" and remove all of them.
• Enable "Always clear my private data when I close Iceweasel". Click "Settings" and check all items. You want to purge everything when closing Iceweasel.

Security:

• On the right-hand side of "Warn me when sites try to install add-ons" click "Exceptions" and remove all exceptions.
• Disable "Tell me if the site I'm visiting is a suspected attack site". Useless crap, possibly a privacy issue.
• Disable "Tell me if the site I'm visiting is a suspected forgery". Useless crap, possibly a privacy issue.
• Disable "Remember passwords for sites". This is a huge security risk, never ever enable it!

Advanced:

• "General" tab:
  • Enable "Warn me when web sites try to redirect or reload the page".
  • Disable "Check my spelling as I type". Useless, annoying crap, which probably even impacts performance.
• "Update" tab:
  • Disable "Automatically check for updates to: Installed Add-ons".
  • Disable "Automatically check for updates to: Search Engines".
  • Select "When updates to Iceweasel are found: Ask me what I want to do".
about:config Open a new tab, enter "about:config" as URL and hit ENTER. Click the annoying "I'll be careful, I promise!" button. Uncheck "Show this warning next time" while we're at it.
• Set browser.urlbar.matchOnlyTyped = true to disable the new, annoying "AwesomeBar" URL bar feature (which is also a huge privacy risk).
• Browser tabs are way too huge for my taste (thus only very few fit on the screen). Fix it with browser.tabs.tabMinWidth = 60 and browser.tabs.tabMaxWidth = 60 (needs a browser restart). You can even use less than 60 if you don't need any text and an icon per tab is enough for you.
• Disable the annoying, flashing auto-search stuff when you select "Tools / Add-ons / Get Add-ons": Set extentions.getAddons.showPane = false.
• Set bidi.support = 0. You'll probably never need it, so reduce the number of potential bugs and security issues by disabling it.
• Self-signed certificate handling is annoying, so fix it with: browser.ssl_override_behavior = 2 and browser.xul.error_pages.expert_bad_cert = true (thanks Pierre Habouzit).
• Set browser.tabs.closeButtons = 3 in order to prevent accidental closing of tabs (no more Close buttons on each tab, only one global Close button on the right). Yes, CTRL+Shift+T helps in case it still happens.
• Set network.prefetch-next = false to prevent random prefetching of webpages which means wasting CPU cycles and bandwidth, as well as subtle privacy and security issues.
Plugins None. Don't even think about installing crap like the closed-source Flash player if stability or security are important to you. If you absolutely must watch YouTube videos, I recommend youtube-dl. Extensions Use as few as possible. Every extention may have security problems or bugs, and can negatively affect performance etc. Pretty much the only one I use is NoScript to selectively enable JavaScript for some trusted websites (and disable it for all other sites).

As last Wednesday was the second anniversary of me joining Google, I thought it an opportune time to reflect on how I've found learning Python. It's no big secret that Google is a Python shop. I'd been meaning to learn it a for a while prior to joining Google, but never found enough reason to other than because it seemed to be the cool new language. If I had a task that required me to write a script, I could do it in Perl in 30 minutes, or spend a day trying to wrap my head around how to do it Python. I think I'd known and been writing Perl in some form or other for about 9 years. I've hardly written any in the last two, which is a bit sad. I even bought Perl Best Practices shortly after moving over here, and haven't gotten around to reading it. The only Perl I write these days is for personal tasks to try and stop myself from going totally rusty. Anyway, I thought I'd write down some of my observations of Python, from a "veteran" Perl programmer's perspective. Not that I consider myself to be a shit-hot Perl coder by any stretch of the imagination... No punctuation I really like the lack of punctuation. It makes the code look a lot cleaner. I go back to Perl and my eyes bleed after trying to dereference a reference to a scalar, or something like that. It's just ugly in Perl. No curly braces/indentation for blocks The indentation thing isn't so bad. If you're using vi, you really need something along the lines of

set shiftwidth=2
set smarttab
set autoindent
set expandtab

in your ~/.vimrc What I do miss is being able to bounce on the % key to find the beginning and ending of a block. I've heard rumours of a way to configure vi to do something similar for Python code, but I haven't gotten around to finding out. There seems to a general opinion that if you're writing a block that is so big you can't find the beginning and end of it, you're probably doing something wrong. String concatenation It's always struck me as bizarre how the most obvious way to concatenate a string in Python is also one of the least efficient. In fact, there's whole studies been done into different methods of string concatenation and their efficiencies. Prototyping is easy Now I may just be ignorant of some Perl shell here, but the number of times I've written a quick Perl script in /tmp to do some proof-of-concept thing is immeasurable. The fact that you can just fire up a Python interpreter and try something quick and dirty to see if it's syntactically sane, or does what you expect is fantastic time saver. ipython makes it an even more pleasant an experience. No CPAN I was initially a bit disappointed that there wasn't something like CPAN for Python modules. In practice, using Debian, I haven't found this to be that big a problem though. List joining is wacky I still find it weird that you don't join a list by a method of the list, you do it by a method of the string you want to use to join the list together with, that is, I think it should be mylist.join(" ") when it's really " ".join(mylist). That's just always struck me as unintuitive. urllib2 doesn't hold a candle to libwww-perl I think even last time I checked with Python 2.5, it's impossible to make a HEAD request. The mind boggles. No setuid support I can't complain too much, I think I heard somewhere it's going away in Perl as well, but it was certainly very convenient to be able to write setuid Perl scripts. I miss that convenience in Python. Not that one has to write setuid scripts all that often. Regular expression handling is painful It's about on a par with Java. You just can't beat Perl's =~ operator. "There's more than one way to do it" versus only one way to do it Perl's always had the adage of there being more than one way to do things. I think that has been its downfall in terms of readability. Heck, I've written some monstrosities that I've looked back on in a month's time and wondered what on earth I was thinking at the time. I think it's far easier to write readable Python than it is to write readable Perl. I think that's about everything. I never did any real object-oriented programming in Perl, and so I tend to take a procedural approach to things in Python as well. I haven't written any massive bodies of code in Python (although I did help maintain one for about 18 months). I like Python. It's become my first choice for writing random scripts now. Now I look at Ruby like I used to look at Python when I knew Perl quite well. Ruby has some nice things (like Perlish regular expression handling), but it brings back all that punctuation noise again. I'm not in a huge rush to learn it, even though there's a lot of hype around Ruby on Rails. I think I'd rather investigate Django or Pylons

Looks like Yahoo! Finance changed their server layout. Data scraping via tools like my Finance::YahooQuote, and those that use it such as my Beancounter toolkit, are therefore inoperational. As a first quick fix, apply the following patch to YahooQuote.pm:

--- YahooQuote.pm.orig  2005-07-17 13:10:20.000000000 -0500
+++ YahooQuote.pm       2007-02-22 18:50:07.000000000 -0600
@@ -34,7 +34,7 @@
 $VERSION = '0.21';
 ## these variables govern what type of quote the modules is retrieving
-$QURLbase = "http://quote.yahoo.com/d?f=";
+$QURLbase = "http://download.finance.yahoo.com/d/quotes.csvr?e=.csv&f=";
 $QURLformat = "snl1d1t1c1p2va2bapomwerr1dyj1x";        # default up to 0.19
 $QURLextended = "s7t8e7e8e9r6r7r5b4p6p5j4m3m4";        # new in 0.20
 $QURLrealtime = "b2b3k2k1c6m2j3"; # also new in 0.20

I will hope to have a first new package out later.

Writing tests is virtuous. It's the wholemeal bread of programming. Do it, and you'll be so much fitter. Except it tastes like cardboard and gets in the way of consuming the yummy treacle sponge of programming. But now I've got the testing religion. I view the lack of tests with the disapprobation of a reformed smoker tutting and huffing at the merest suggestion of a Marlboro Light. How did this happen and how can I be sure I won't backslide? The moment of transition was the first time that a test saved me from releasing software with a bad bug in it. The theoretical knowledge of virtue was translated into the palpitating relief of not disgracing myself in public. After that happened a few more times, I found myself desperately uncomfortable with the idea of releasing anything that didn't have decent test coverage. And so a virtuous habit is formed. It's not just driven by fear. With the right tools to hand, writing tests can be a lot of fun. You don't always need to be "in the zone". If you've got a spare half hour here and there, you can use it to increase the coverage of your tests. Getting better at testing is one of the ways I've become a much more proficient Rails developer over the last year of work on Expectnation. In case it helps anybody else, I thought I'd share some of the tools and techniques that are part of making Rails testing fun and effective. Continuous testing Whenever a checkin is made to our source repository, tests are run and the results emailed to everybody working on the project. As with the "you broke the build" disincentive, you need to be kept honest by frequent running of the tests. There are a variety of tools around to help you do continuous integration with Rails, most of which have some dependence on you using Subversion for source control. In the event, I just created my own script to do what we required. Coverage reports One of the big mental hurdles with testing is knowing how many tests you should aim for.  You can't prove a negative: even if your tests are all passing it still doesn't tell you much about the tests you haven't written that might fail! We use rcov as part of the continuous integration process, and post the results to our project web site. The pretty red and green bars give you some idea of when you're starting to get adequate test coverage, and the line-by-line breakdown is invaluable. Tainting strings One of the easiest errors to make in Rails templates is to miss the call to h(), to escape any HTML in an output string. The only real way to catch these errors is through automation. The wonderful safe_erb plugin helps you do just that. By using Ruby's tainting mechanism for strings, it throws an exception if you render any external data unescaped. One of the beneficial side effects of safe_erb is that you then become very particular about ensuring your functional tests properly cover every action in your application.  Tests such as get 'index', which before seemed mundane and redundant, are now essential, as you want to test for tainted strings. In addition to the above techniques, there are a lot of fun shiny gadgets to help you write tests, such as ZenTest, but the three things above are the ones I've found to be of significant value. I ought to conclude with words of praise for Rails. It goes out of its way to make testing an important part of the development lifecycle, and the availability of the of unit, functional and integration test functionality makes it easy to get started. Every time I teach somebody about Rails' testing features, they end up finding it very enjoyable.
Don't forget, testing can be fun!

Long day today (yesterday, actually, but I'm post-dating this in the interest of chronological flow). The baby's having a hard time coming off of West Coast time; she got up late and took a loooong nap till half-past three. Which was fine, because I needed the time to work on my NSLU2, which needed some attention. The NSLU2, or "Slug", is a tiny Linux computer from Linksys, about the size of a two packs of Marlboros laid side-by-side. My brother Nate gave me one last year for Christmas (thanks, nate), and I've been using it for network backups, but on our trip to SF Nate showed me that he's running all kinds of wild services off of his. So I decided to start shifting over some responsibilities to the little bugger. Which was just about time. Sometime during our trip to San Francisco, my main home server started having fan problems; it kept overheating and shutting itself down. It's going to take some time to diagnose the problem, but I figured that this was as good a time as any to move the critical services over to the Slug. The main one that needed budging was DNS. Maj's main domain, as well as my two .san-francisco.ca.us domains, run from home, because it's too hard to get the registrar to change them. The Unslung system I use for the Slug has a BIND package, which is a good thing to run, anyways. I was running MaraDNS on the big server, because I always root for the underdog, but there wasn't a MaraDNS package for the Slug. So I rewrote my zone files and things are up and running now. I don't know what else I'm going to put on there. Jabberd? Asterisk? A home wiki? Just not sure. tags: nslu2 slug unslung baby

Blah blah blah When the baby got up, we went to our local Loblaws, out towards the end of rue Rachel across from Canadian Tire. It's a pretty fantastic place to buy groceries -- it's the old CPR Angus Shops, a repair and maintenance facility for the Canadian Pacific Railway. The building is huge, with giant cranes and beams still attached to the roof. Amita and I grabbed a crapload of groceries and brought them home to Maj, who'd just had a massage at the centre around the corner and was feeling really good. She'd rented Tristram Shandy, the 2005 movie based on the 18th-century level-twisting novel. Me and Amita June made some baked potatoes, and we all watched the movie, and a good time was had. tags: tristram shandy loblaws angus shops movie maj amitajune

H****e en vrac One thing I always want to buy when I'm at the store in Quebec is the quite commonly available communion wafers. Yeah, really! big ol' 5-inches-diameter communion wafers, in the snack section next to the Doritos and the Humpty Dumpty potato chips. Quebec society has a had a precipitous secularization -- from around 90% church attendance in the 1950s to less than 10% today. But Catholicism still infuses all parts of life. For example, in Quebec, you cuss by using words from the church, including, of course, hostie ("the host"). So I can't figure out why hostie are a tasty snack treat. Is it a deliberate snub to the sacrament of communion by a secular society? Or did the practice antedate the Quiet Revolution, and did the formerly religious Quebecois eat communion wafers for fun? Or is it just a snork-snork funny thing to do, when the name of the food is actually a naughty word? I dunno. I'm fascinated, but not enough to buy a big bag of communion wafers to eat. (They're never cheese- or BBQ-flavored, by the way; they have a pristine seriousness to them.) More info solicited. tags: hostie quebec snack food

Opinity One of the services mentioned in the Web 2.0 Summit infrastructure workshop was Opinity. Opinity seems to be a distributed reputation system, kind of like claimID but with a little more soft information. I think it looks pretty cool, and I'm glad to see another addition to the growing OpenID identity provider market. tags: openid opinity identity reputation

There are a several events coming up where I plan to hold my Shell Quoting Talk: First, there will be the BarCamp Zurich on October, the 28th at ETH Z rich HG and then there will be the 8th Linuxday.at on November, the 18th at the HTL at Dornbirn (Vorarlberg, Austria) organised by the LUG Vorarlberg. It’s also possible that, in addition to the Shell Quoting talk, I’ll also give a talk for beginners about Commandline Helpers. (Probably all the talks will be held in German.) I’m quite curious on both events, for very different reasons. On the one hand, a BarCamp is something completely new for me and it sounds like a very interesting mixture of a real life Wikipedia meeting and a flash mob to me. On the other hand, this year’s Linuxday.at will have several new facettes for me: First there were several changes in the organising team, so I wonder if and in that case how much this will change the face of the event. Then it’s the first Linxuday.at since I live in Zurich, which means it’s the first Linuxday without 1000km travelling during that weekend, so I also have some time to meet friends in the area in advance to or after the event. Yeah!

While evaluating Gallery, I noticed that my test web server generates wrong links inside the web application. After getting some help on the Gallery Forum, I was told that this was because my setup was miscreating REQUEST_URI to contain the entire URI, consisting of scheme, host name and path, while Gallery expects that variable to be only the path portion of the URI. Since REQUEST_URI is fine when I ask the web server running the application directly from the host in question, while accessing it from my local machine through an ssh tunnel (since the application web server is not going to be publicly visible on the Internet) yields the full URI in REQUEST_URI Unfortunately, neither is the PHP Documentation especially verbose (it just says that REQUEST_URI is “The URI which was given in order to access this page; for instance, ‘/index.html’.”) nor is the apache documentation formally defining REQUEST_URI (the closest to a definition being the documentation for mod_setenvif, which says that REQUEST_URI is “generally the portion of the URL following the scheme and host portion without the query string”). Did I miss a more formal documentation of apache/PHP’s behavior? Pointers appreciated. While I was writing this blog entry, which was a lot more angry in its first version, the Gallery guys finally acknowledged that apache and PHP are not sufficiently specifying REQUEST_URI and that I have delivered a valid example where there is a host part in REQUEST_URI. They’re going to work around this. Good news, thanks!

---

The promised fix is in gallery2 svn, I have applied the patch to my local version, and the application is fine now. Thanks!

I just fixed some RC bugs in my packages to get my ass not kicked.
I uploaded a small update for apt-build. I tried to use it, and it seems to be totally dead. Trying to build blackbox (my reference test, this is historical), make died with a segfault, and at the end, apt-build died with a segfaults. Yee-pee ! And I don't know why, this is weird. I also asked the removal of torsmo (superseded by conky) and orphaned manderlbot, since I have no skill in Erlang. I also find out why I could not fix the f****** FTBFS on svnmailer. And it was because the -I.svn option of dpkg-buildpackage I used, skipped the svnmailer.conf.example file, obviously... Raaahhh, bad shell alias configuration => headache !